Creating individually tailored care plans

ABSTRACT

One or more described embodiments relate to techniques for generating a care plan tailored for an individual. A care plan for treatment of one or more medical conditions for a patient is generated based on care protocol templates. The generating includes identifying a first patient task that conflicts with a second patient task, in the care protocol templates. The care protocol templates are parsed to identify a conflict resolution rule, pre-defined in a respective template, and the conflict is resolved by generating a patient task based on the conflict resolution rule and including the patient task in the care plan. The care plan is transmitted to a client device for the patient. The client device is configured to use the care plan to configure one or more sensor devices to collect biometric data as part of the treatment of the one or more medical conditions for the patient.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present disclosure is a continuation of co-pending U.S. patentapplication Ser. No. 14/490,413 filed on Sep. 18, 2014 which isincorporated herein by reference in its entirety.

BACKGROUND Field

Embodiments presented herein generally describe techniques related tohealth care, and more specifically, for generating an individualizedcare plan for a patient.

Description of the Related Art

In the health care field, a care plan is a set of tasks provided by ahealth care practitioner (e.g., a doctor) to a patient. Historically,such a care plan is a written document that provides directions androutines for the patient to follow to manage certain health conditions.The care plan may include a set of tasks (e.g., exercise for a givenduration) for the patient to perform, content that educates the patientabout a diagnosed condition (e.g., brochures describing the diagnosedcondition), and logs for the patient to periodically record informationin (e.g., weight, blood pressure, etc.). As an example, a doctor mightcreate a care plan for a patient with hypertension that includes severalbrochures describing hypertension and hypertension treatment andassigned tasks such as walking on a treadmill for thirty minutes eachmorning, drinking a glass of water every three hours, and recordingblood pressure at the end of each day. Thus, as part of the treatment ofthe condition, the patient is expected to adhere to the tasks listed inthe care plan and to then follow up with the doctor in a subsequentappointment to assess the patient's progress.

The current care plan approach has several shortcomings. For instance, acare plan for a particular condition is often tailored towards thecondition itself, without considering relevant details about a patient.Typically, once a doctor has diagnosed a patient with a particularcondition, the doctor prints out a “one size fits all” care plan for theindividual that instructs the individual on how to manage the condition.Although the doctor may include notes in the printed pamphlet describingthe care plan, the doctor is often unable to modify the care planotherwise (e.g., to craft the care plan specifically for the patient).Further, the doctor often has no way of determining the patient'sadherence to the care plan until a follow-up appointment. Currently, toaddress this concern, care providers employ call centers to contact thepatient periodically and determine whether the patient is following thecare plan, but such an approach is costly and further exposes apatient's condition to more individuals than necessary.

SUMMARY

One embodiment provides a method. The method includes generating, usinga processor at a care platform server, a care plan for treatment of oneor more medical conditions for a patient, based on a first care protocoltemplate associated with a first treatment for the patient and a secondcare protocol template associated with a second treatment for thepatient. The generating includes identifying, using the processor at thecare platform server, a first patient task associated with the firstcare protocol template that conflicts with a second patient taskassociated with the second care protocol template. The generatingfurther includes parsing, using the processor at the care platformserver, the first and second care protocol templates to identify a firstconflict resolution rule. The first conflict resolution rule ispre-defined in a respective template prior to the identifying theconflict. The method further includes resolving the conflict bygenerating a third patient task, based on the first conflict resolutionrule, and including the third patient task in the care plan. The methodfurther includes transmitting the care plan to a client device for thepatient. The client device is configured to use the care plan toconfigure one or more sensor devices to collect biometric data as partof the treatment of the one or more medical conditions for the patient.

Still another embodiment includes a non-computer-readable storage mediumstoring instructions, which, when executed on a processor, perform anoperation. The operation includes generating, using the processor at acare platform server, a care plan for treatment of one or more medicalconditions for a patient, based on a first care protocol templateassociated with a first treatment for the patient and a second careprotocol template associated with a second treatment for the patient.The generating includes identifying, using the processor at the careplatform server, a first patient task associated with the first careprotocol template that conflicts with a second patient task associatedwith the second care protocol template. The generating further includesparsing, using the processor at the care platform server, the first andsecond care protocol templates to identify a first conflict resolutionrule. The first conflict resolution rule is pre-defined in a respectivetemplate prior to the identifying the conflict. The operation furtherincludes resolving the conflict by generating a third patient task,based on the first conflict resolution rule, and including the thirdpatient task in the care plan. The operation further includestransmitting the care plan to a client device for the patient. Theclient device is configured to use the care plan to configure one ormore sensor devices to collect biometric data as part of the treatmentof the one or more medical conditions for the patient.

Still another embodiment includes a system having a processor and amemory a memory storing one or more application programs configured toperform an operation. The operation includes generating, using theprocessor at a care platform server, a care plan for treatment of one ormore medical conditions for a patient, based on a first care protocoltemplate associated with a first treatment for the patient and a secondcare protocol template associated with a second treatment for thepatient. The generating includes identifying, using the processor at thecare platform server, a first patient task associated with the firstcare protocol template that conflicts with a second patient taskassociated with the second care protocol template. The generatingfurther includes parsing, using the processor at the care platformserver, the first and second care protocol templates to identify a firstconflict resolution rule. The first conflict resolution rule ispre-defined in a respective template prior to the identifying theconflict. The operation further includes resolving the conflict bygenerating a third patient task, based on the first conflict resolutionrule, and including the third patient task in the care plan. Theoperation further includes transmitting the care plan to a client devicefor the patient. The client device is configured to use the care plan toconfigure one or more sensor devices to collect biometric data as partof the treatment of the one or more medical conditions for the patient.

BRIEF DESCRIPTION OF THE DRAWINGS

So that the manner in which the above recited features of the presentdisclosure can be understood in detail, a more particular description ofthe disclosure, briefly summarized above, may be had by reference toembodiments, some of which are illustrated in the appended drawings. Itis to be noted, however, that the appended drawings illustrate onlyexemplary embodiments and are therefore not to be considered limiting ofits scope, and may admit to other equally effective embodiments.

FIG. 1 illustrates an example computing environment, according to oneembodiment.

FIG. 2 further illustrates the care platform server described in FIG. 1,according to one embodiment.

FIG. 3 illustrates an example care protocol template, according to oneembodiment.

FIG. 4 illustrates a task view of the care protocol template describedin FIG. 3, according to one embodiment.

FIG. 5 illustrates a method for generating a care plan, according to oneembodiment.

FIG. 6 illustrates a sequence for creating a care plan based on careprotocol templates to associate with a patient, according to oneembodiment.

FIG. 7 illustrates a care platform server configured to generate a careplan, according to one embodiment.

To facilitate understanding, identical reference numerals have beenused, where possible, to designate identical elements that are common tothe figures. It is contemplated that elements and features of oneembodiment may be beneficially incorporated in other embodiments withoutfurther recitation.

DETAILED DESCRIPTION

Current approaches for providing a care plan to a patient are rigid. Forexample, in many cases, a physician who has diagnosed a patient with aparticular condition may provide the patient with a generalized careplan commonly used to address that condition. Frequently, thesegeneralized care plans are pre-printed documents that are not tailoredto any particular patient but rather generally address the diagnosedmedical condition. As a result, such printed care plans do not allow thephysician to customize the care plan beyond annotating the care planalong the physical and behavioral margins. Such an approach isinconvenient when the physician must address multiple conditions througha care plan. Further, to address multiple conditions, a physiciantypically has to print separate care protocol pamphlets addressing eachof multiple medical conditions the patient has been diagnosed with.Because some tasks in each of the printed pamphlets may overlap (e.g.,two different care plans may instruct a patient to take a certain dosageof aspirin at a given time of day), a patient may have difficultyunderstanding the tasks to perform, leading to poor compliance.Moreover, in some situations, the tasks for treating the variousdiagnosed conditions may conflict with one another, leaving the patientunsure as to how to reconcile the conflict.

Embodiments presented herein describe techniques for generating acustomized health care plan for an individual. In one embodiment, a careplatform is provided that allows a physician to design a care plantailored specifically for an individual patient. The care plan mayinclude multiple care plan protocols, with each of the care planprotocols addressing a respective medical condition the patient has beendiagnosed with. Generally, a care plan protocol describes the treatmentof a particular medical condition. For instance, a care plan couldspecify a set of specific tasks for a patient to follow to manage theparticular medical condition and could divide the tasks by phases andschedules. Generally, different care plan protocols may be available foreach of a variety of conditions, such as congestive heart failure,diabetes, sprained ankle, etc. In addition, the care protocol mayspecify metrics that the care platform monitors during the patient'streatment, thresholds to detect for each metric, and remedial actions tobe taken in response to detecting such thresholds. One example metric isblood pressure. The blood pressure metric may be associated withthresholds indicating values and conditions in which the care platformperforms some action in response to detecting such values andconditions, e.g., sending instructions to the patient to rest for agiven period of time. Further, the care protocol may provide the patientwith resources to educate the patient about a diagnosed condition,treatment, and the like (e.g., instructional videos, articles, etc.).

A physician may assign multiple care plan protocols to a patientsuffering from multiple medical conditions. To do so, the physician mayconfigure templates for care plan protocols corresponding to thepatient's conditions. Each care protocol template provides a general setof tasks to follow for a given condition. In one embodiment, thephysician may configure the protocols for a specific patient via a userinterface provided by the care platform. For example, assume a careprotocol template for congestive heart failure recovery specifies anumber of tasks to be performed at a specified interval (e.g., daily),such as walk for fifteen minutes, take prescribed medicine, record bloodpressure, and record weight. If the physician deems that the patient isalready within a healthy weight, the physician may remove the “recordweight” task from the protocol. Further, the physician may also adjustthe length of time that the patient should walk. In addition, thephysician may insert additional tasks to the protocol.

Further, the physician may customize metrics specified in the careprotocol and thresholds associated with each metric. Continuing theexample of a care protocol for congestive heart failure recovery, thecare protocol may specify a heart rate metric as well as a thresholdthat alerts the physician whenever the patient's heart rate is over avalue X. In such a case, the physician may adjust the threshold, such asby adding conditions that need to be satisfied before alerting thephysician, e.g., in order to trigger an alert due to the patient's heartrate being above a value X, the patient's activity level must be below avalue Y.

The care platform may consolidate the configured care plan protocolsinto one overall care plan for the patient. However, it is possible thatsome tasks and phases of different care plan protocols overlap. As such,the care platform may perform operations to reconcile any conflictsbetween care plan protocols as part of the care plan creation. Forexample, a care plan protocol for high blood pressure and another fordiabetes may include a step for walking for ten minutes each day. Bothprotocols may also include a step for taking two aspirin pills in themorning, and including two separate steps for taking aspirin may yieldunintended consequences related to a dosage that the patient should betaking. As such, the care platform could consolidate the two separatetasks into a single task of taking two aspirin pills each morning.

In one embodiment, each task and threshold in a care plan protocol hasan associated conflict resolution rule that the care platform evaluateswhen consolidating protocols. The conflict resolution rule may specifywhether and how a given task (or threshold) may be merged withoverlapping tasks (or thresholds) in other protocols. For example, thecare platform may specify that tasks requiring a patient to takemedication should be merged with other tasks involving the samemedication. In addition, the conflict resolution rule may specifywhether two or more overlapping tasks should be performed in separately.Further, the care platform may reconcile similar tasks that occur atdifferent periods of the day based on the conflict resolution rules foreach task. For example, a task for a congestive heart failure protocolmay instruct the patient to take a dosage of aspirin in the morning,where another task for a sprained ankle protocol may instruct thepatient to take a dosage of aspirin in the evening. Moreover, each ofthe care plan protocols could further specify that while a daily aspirindosage of a particular amount is needed, the timing of the daily dosageis flexible. As such, the care platform could resolve the timingconflict between the two exemplary care protocols by specifying thatonly a daily dosage of the particular amount of aspirin should be taken.In other situations, the care protocols could specify conflictresolution rules for each task which indicate that both tasks may beincluded in the same care plan.

Once created, the care platform may transmit the care plan to anapplication in a device owned by the patient, e.g., a smart phone ortablet device. Though the device, the patient may access the care planand understand the tasks to perform. Further, the application mayreceive information from various sensors that monitor patient activity(e.g., heart rate, weight, blood pressure). The application can recordthe information to the care plan and relay information to the careplatform. As a result, the physician (or members of the patient's careteam such as caregivers) can monitor the patient's adherence to the careplan.

In one embodiment, each task set out in the care plan may be associatedwith an observation threshold, such that when patient activity reaches aparticular threshold, the care platform may take a certain action inresponse, such as notifying the physician. Another example of an actionthat the care plan may take is prompting the patient to report symptomsvia the mobile device. Input from the patient may be used to assist thecare platform in interpreting metrics and determining whether toescalate care. That is, symptoms reported by the patient may be includedas a threshold condition, such that if particular symptoms are noted incombination with given metrics, the care platform may take furtheraction, such as by including additional tasks to reorient observedmetrics to an acceptable level or by alerting a physician or emergencyservices.

Moreover, the care plan could perform treatment operations responsive todetecting an observation metric that exceeds a threshold value, beforeescalating to a physician or emergency services. For example, upondetecting the patient's heart rate exceeds a threshold value while thepatient's overall activity level is relatively low, the care platformcould present the patient with instructions (e.g., via the mobiledevice) to sit and rest for a period of time. If the patient's heartrate remains elevated after the patient has complied with theinstructions, the care platform could then determine that more urgenttreatment is needed and could alert emergency services as to thepatient's condition. As stated, the physician may create, edit, orremove observation thresholds while configuring a care protocoltemplate. For example, for a task that requires a patient to record adaily weight, the physician may specify a threshold weight gain at whichto generate an alert, e.g., if the patient gains two pounds after a day.

FIG. 1 illustrates an example computing environment 100, according toone embodiment. As shown, the computing environment 100 may include acare provider environment 105 and a patient environment 130, eachconnected to one another via a network 145. The environments 105 and 130allow a patient 103 to communicate with a care provider 101 (e.g., aphysician).

The care provider environment 105 includes a care platform server 110, aphysician device 120, and a portal 125. Each of the care platform server110, physician device 120, and portal 125 may be a physical computingsystem or may be a virtual computer instance (e.g., executing in a cloudcomputing platform). A care provider 101 may use the physician device120 to access (e.g., via a browser application 122) a portal userinterface 126 hosted by the portal 125. The portal user interface 126itself provides users 102 (e.g., the care providers 101) with access tothe care platform server 110.

The care platform server 110 includes various applications and data thatallow a care provider 101 to create and manage a care plan for a patient103. As shown, the care platform server 110 includes a care planmanagement application 111, policy information 112, patient information113, care protocol templates 114, and care plans 115. The care planmanagement application 111 generates care plans 115 based on careprotocol templates 114.

A care plan 115 may be created based on one or more care protocols, witheach of the care protocols relating to a respective medical conditionthe patient has been diagnosed with. A care protocol is a set of tasksthat a patient 103 follows to manage a certain condition, metrics thatthe care plan management application 111 monitors, objectives for thepatient to meet, and the like. For instance, a care protocol may targetrecovery from a heart attack. Another care protocol may treat diabetes.Tasks associated with a care protocol may include steps such asexercising for a specified duration or taking medication at a certaintime of day.

Further, each care plan protocol may be divided into different phases.The phases may represent different stages of care for a particularcondition, e.g., a recovery phase, a maintenance phase, etc., where eachphase may include a respective set of tasks for the patient to perform,observation metrics to monitor, observation thresholds to detect whenthe monitored metrics satisfy specified conditions. For example, a careprotocol for weight management may include several phases. A patient 103may begin the care protocol at a weight loss phase, where tasks mayinclude performing strenuous exercises frequently, and where thresholdsmay specify further actions that the care plan management application111 takes if the patient 103 loses X amount of weight or gains Y amountof weight. For example, if the metrics indicate that the patient 103gained Y amount of weight after a period at which the patient 103 had aZ average activity level, the care plan management application 111 mayinstruct the patient 103 to watch an educational video in response.Continuing the example, if the patient 103 loses X amount of weightduring a given period, the care plan management application 111 maytransition the care protocol to a weight maintenance phase, where tasksmay include exercises that assist the patient 103 in maintaining theweight.

Each care plan protocol may also include observation thresholdsassociated with monitored metrics and could further specify an action(s)to be taken responsive to an observation threshold being satisfied. Thecare platform server 110 may monitor the adherence of a patient 103through various sensor devices 140 that can measure heart rate, weight,blood pressure, and the like. The care platform server 110 may takespecified actions if one of the metrics crosses a correspondingthreshold, e.g., if a patient 103 gains 1.5 pounds after a day, theplatform server 110 may report the weight gain to the care provider 101.

To generate a care plan, a care provider 101 may configure care protocoltemplates 114 corresponding to medical conditions the patient 103 isdiagnosed with. To do so, the care provider 101 (e.g., via the portaluser interface 126) selects one or more care protocol templates 114 toassociate with the patient 103. The care plan management application 111copies the selected templates to a care plan 115, i.e., the care planmanagement application 114 populates the care plan 115 with tasks,triggers, and monitoring thresholds as specified by the selected careprotocol templates 114. The portal user interface 126 may display theselected care protocol templates 114, where the care provider 101 maycustomize various facets of each selected template 114, such as tasksand thresholds. For example, the care provider 101 may customize a taskinstructing a patient to check blood pressure every morning. The careprovider 101 may adjust the task so that the patient checks bloodpressure twice a day. In addition, the care provider 101 may adjustthresholds associated with that task, such that the care platform server110 alerts the care provider 101 if a threshold blood pressure isreached.

In one embodiment, each customization may be subject to comply withpolicy information 112 and such compliance may be enforced by the careplan management application 111 during the creation of the care plan.Policy information 112 may include various guidelines (e.g., set by ahospital, standards organization, insurance companies, etc.) that eachcare protocol must adhere to. For instance, the policy information 112may specify milligram ranges for certain medications that may beassigned to a patient 103 in a care protocol. The care plan managementapplication 111 may enforce such policy information 112 to ensure a careprovider 101 configuring a care plan does not customize tasks beyond thebounds of the policy information 112.

The care plan management application 111 generates a care plan 115 for apatient 103 based on the customizations made by the care provider 101.In doing so, the care plan management application 111 identifiesconflicting tasks across the selected care protocols. For example, acare protocol for high blood pressure may include a task instructing apatient to take 75 milligrams of aspirin three times a day, whileanother care protocol for a sprained ankle includes a task instructingthe patient to take 100 milligrams of aspirin three times a day.

Generally, the patient information 113 represents patient-specificinformation describing a patient's medical history and treatmenthistory. In one embodiment, the care plan management application 111 maygenerate the care plan 111 based on the patient information 113, inaddition to customizations to care protocol templates 114 that the careprovider 101 provides. Patient information 113 may include medicationspreviously prescribed to the patient 103 and whether the medications hada beneficial or adverse effect towards the patient. In a case where aparticular medication has had an adverse effect towards a patient 103,the care plan management application 111 may flag tasks associated withtaking the medication to the care provider 101 configuring the care plan115. In response, the care provider 101 may edit or remove the task.

Once generated, the care plan management application 110 may store thecare plan 115 on the care platform server 110. Further, the care planmanagement application 110 transmits the care plan 115 to a mobiledevice 135 (e.g., to a patient care application 136 executing on themobile device 135) of the patient 103. The patient 103 views the careplan (shown as care plan 137) on the mobile device through the patientcare application 136. Doing so allows the patient 103 to understandtasks needed to adhere to the platform. Further, the care plan 137 istightly coupled to the corresponding care plan 115. Any updates toeither care plan 115 or 137 are synced with one another.

Moreover, the mobile device 135, upon receiving the care plan, couldconfigure one or more monitoring devices to monitor one or more patientmetrics as specified by the care plan. For example, the mobile device135 could configure logic on a heart rate monitor device worn by thepatient to monitor the patient's heart rate and to detect when thepatient's heart rate exceeds a threshold number of beats per minutespecified within the care plan. The heart rate monitor device, upondetecting that the threshold condition has been satisfied, couldtransmit an alert to the mobile device 135, which could in turn performan action as specified by the care plan. For example, the mobile device135, upon receiving the alert, could display a notification to thepatient, informing the patient that his heart rate is elevated andinstructing the patient to sit down and rest for a period of time. Asanother example, the mobile device 135 could generate a notification tothe care plan management application 111, informing the care planmanagement application 111 that the patient's heart rate exceeds thethreshold amount of beats per minute.

The patient care application 136 may display information related to thecare plan 137, such as phases, tasks, and other information aboutconditions targeted for treatment by the care plan 137. When the patient103 performs a task, the patient 103 records progress in the patientcare application 136. The patient care application 136 relays thisinformation to the care plan management application 111. Doing so allowsthe care provider 101 to monitor vitals of the patient 103 and adherenceto the care plan. Further, depending on how the patient 103 responds tothe care plan 137, the care plan management application 111 may adjustcertain tasks.

In one embodiment, sensor devices 140 may interact with the patient careapplication 136 and assist the patient 103 in reporting body-relatedmetrics to the care platform server 110. As shown, such sensor devices140 may include a body sensor 141, a weighing scale 142, and a bloodpressure cuff 143. Each of the sensor devices 140 may capture differentbody metrics of the patient 103. For example, when applied to the bodyof patient 103, the body sensor 141 captures biometric data (e.g., heartrate) in real-time. In addition, each of the sensor devices 140 may beconfigured to transmit the body-related metrics electronically to thepatient care application 136 on the mobile device 135. In turn, thepatient care application 136 sends the captured metrics to the care planmanagement application 111.

FIG. 2 further illustrates the care platform server 115, according toone embodiment. As stated, the care plan management application 111 canbe configured to generate a care plan 115 based on care protocoltemplates 114 selected by a care provider 101 and also based on policyinformation 112 and patient information 113.

As shown, the care plan management application 111 further includes aplan generation component 205 and an inventory management component 210.The plan generation component 205 receives selections of care protocoltemplates 114 from a care provider 101. The plan generation componentmay populate a care plan 115 with the phases, tasks, and thresholdsspecified in each of the care protocol templates 114 selected by thecare provider 101.

Further, the plan generation component 205 may receive customizations tothe tasks and thresholds of the care protocol templates 114. Inaddition, the care provider 101 may insert tasks and thresholds to anyof the care protocol templates 114. The plan generation component 205generates the care plan 115 based on the care protocol templates 114 andthe care plans 115. In doing so, the plan generation component 205ensures that any customizations to the care protocol templates 114 madeby the care provider 101 comply with policy information 112.

Further, the plan generation component 205 resolves task and thresholdinformation that conflict between different care protocol templates. Inone embodiment, tasks and thresholds may be associated with conflictresolution rules such that in the event a conflict arises, the plangeneration component 205 may resolve the conflicting tasks andthresholds based on such properties. The properties may be configured bycare providers 103. For example, assume that a care protocol template114 for a sprained ankle condition includes a task instructing a patientto take 80 milligrams of aspirin in the morning. Assume also that a careprotocol template 114 for hypertension includes a task instructing apatient to take 150 milligrams of aspirin in the morning. A conflictresolution rule for the task of taking aspirin in the morning mayspecify that in the event of a conflict, the task instructing thepatient to take the higher dosage should override. Thus, when a careprovider 103 selects the care protocol templates 114 for a sprainedankle and hypertension for a patient, the plan generation component 114reconciles the conflicting tasks by inserting the 150 milligrams ofaspirin step in the care plan and disregarding the 80 milligrams ofaspirin step. Another example of a conflict that may arise includesdifferent care protocols instructing a patient to take two types ofmedication that should not be taken together. Conflict resolution rulesfor such tasks may include logic to avoid such combinations or raise aflag to the care provider 103 selecting the protocols. The care provider103 may further customize the care protocol templates 114 in response.

In one embodiment, the plan generation component 205 may make additionalcustomizations based on patient information 113. As stated, patientinformation 113 may include patient medical histories. Such historiesmay contain past treatment information for a given patient as well asinformation on the effectiveness of certain treatments to the patient.The patient information 113 may include other data such as allergies,past afflictions, etc. The plan generation component 205 may adjusttasks based on the patient information 113. For example, if the patientinformation 113 indicates that a patient is allergic to ibuprofen, theplan generation component 205 may substitute tasks mentioning ibuprofenwith a similar medication. Alternatively, the plan generation component205 may flag the task for further review by the care provider 101.

The inventory management component 210 maintains a store of sensordevice configurations for patients registered with the care environment.The inventory management component 210 associates the patient careapplication 136 with the sensor devices 140. Further, the inventorymanagement component 210 also associates a generated care plan with thepatient care application 136 and sensor devices 140. Doing so ensuresthat the plan generation component 205 sends a generated care plan tothe correct mobile device as well as configures the patient careapplication 136 and sensor devices 140 of the patient 103 with therelevant threshold information. Further, the inventory managementcomponent 210 maintains device integrity and ensures ease of use for thecare provider 101. Once configured, the patient care application 136allows the patient 103 to begin adhering to the individualized careplan.

FIG. 3 illustrates an example care protocol template 300, according toone embodiment. In one embodiment, a copy of the care protocol template300 may be presented to a care provider 101 via a web browser interface.For example, the care provider 101 may access a portal server thatpresents the interface to the care provider 101. After entering arequest to create a care plan, the interface may present the template300 to the care provider 101. The care provider 101 enters informationinto and modifies a copy of each template 300. After doing so, the plangeneration component 205 may create the care plan based on the templatesand customizations.

As shown, the template 300 includes fields 305 and 310, where the careprovider 101 may enter a name and an identifier of a patient toassociate with a care plan. In addition, the template 300 includes adrop down menu 315 that allows the care provider 101 to select aparticular care protocol. The drop down menu 315 may include a list ofconditions for which a care protocol exists and is licensed in the careplatform server. In this case, the care protocol shown is for high bloodpressure.

After selecting a care protocol via the drop down menu 315, theinterface may present tasks, thresholds, and metrics associated with thecare protocol. For instance, the bottom half of the template 300 showsphase and task information associated with the care protocol for highblood pressure. The care provider 101 may modify a variety of tasks andother information associated with the care protocol. For example, thetemplate 300 includes a field 320 that allows the care provider 101 tospecify a duration for the care protocol to last.

In addition, the template 300 allows the care provider 101 to view phaseinformation 325 associated with the protocol. The care provider 101 mayselect a phase to view using a drop down menu 330. After selecting aphase, the care provider 101 may view tasks associated with a particularphase, e.g., via a drop down menu 335. The template 300 may allow thecare provider 101 to edit or remove selected tasks. The care provider101 may also add tasks for phases and tasks to be across all phases aswell.

Once the care provider 101 is finished customizing the selection, thecare provider 101 may save the customizations. The plan managementcomponent 205 may allow the care provider 101 to add other care planprotocols until the care provider 101 has selected all the neededprotocols for a patient.

FIG. 4 illustrates a task view 400 of the care protocol template 300,according to one embodiment. The task view 400 provides additionalmetrics that a care provider 101 may evaluate and edit for a given careprotocol when creating a care plan to assign to a patient. As shown, thetask view 400 includes fields 405, 410, and 415 that indicate a patientname, a patient ID, and a care protocol condition. The bottom half oftask view 400 lists tasks associated with the selected care protocol. Inthis case, the tasks are associated with a “high blood pressure” careprotocol.

As shown, the task view 400 lists the tasks in a column 420. Each taskin the list 420 specifies an instruction that a patient should take,e.g., wearing a body sensor, taking blood pressure, and taking 60milligrams of aspirin. Further, the task view 400 provides a column 425specifying a frequency at which to perform a corresponding task, e.g.,taking 60 milligrams of aspirin every morning.

The task view 400 also lists observation threshold sets 430 that a careprovider 101 may configure. Each threshold set may correspond to aparticular task metric in a care protocol, e.g., that is monitoredthough a sensor device associated with a patient. As shown, eachthreshold set 1 includes columns associated with a threshold type, avalue, a warning level, associated symptoms reported by a patient (e.g.,via the patient care application 136), and alert type. Each threshold isassociated with a tier-based warning level that indicates a severity ofthe threshold. For example, a tier 1 warning level may be of a mildseverity, while in contrast, a tier 3 warning level may be of a highseverity. If a patient reaches a particular observation threshold, thecare platform server may take a specified action, such as recording theevent to a medical chart of a patient, notifying a care provider 101,etc. The care plan management application 111 may also prompt thepatient 103 to report any symptoms (e.g., via the patient careapplication 136). Based on rules associated with the threshold triggers,the care plan management application 111 may elevate the warning levelto the next tier in response to reported symptoms being noted with theobserved metrics. For example, if the care plan management application111 detects, based on a specified threshold, that the heart rate of thepatient is over a value X, the care plan management application 111 mayinstruct the patient to rest and also prompt the patient to entersymptoms. If particular symptoms (specified in the threshold) arepresent, the care plan management application 111 may elevate to thenext tier in response. However, if no (or other) symptoms are present,then the care plan management application 111 may continuously monitorthe heart rate of the patient for a given time period to determinewhether the heart rate drops within an acceptable range, and actaccordingly after the end of the time period.

Consider threshold set 1 shown in the task view 400. Threshold set 1corresponds to thresholds related to monitoring weight over a weeklybasis. If the care platform server detects that a patient associatedwith the care plan has gained 2.5 kilograms over a weeklong period, thecare platform server may record the information on the patient's medicalchart.

A care provider 101 may add, delete, or modify observation thresholds asnecessary. Further, the care provider 101 may add or delete thresholdsets for associated tasks, as well.

FIG. 5 illustrates a method 500 for generating a health care plan thatmay be customized for an individual, according to one embodiment. Assumethat a care provider (e.g., a physician, clinician, medicalprofessional, etc.) has sent a request to the care platform server 110to create a care plan for a patient and that in response, the care planmanagement application 111 has sent a number of selectable care protocoltemplates to the care provider.

Method 500 begins at step 505, where the plan generation component 205receives a selection of one or more care protocol templates. Forexample, assume that the plan generation component 205 receives aselection of a care protocol template for diabetes and a care protocoltemplate for high blood pressure.

For each selection, the plan generation component 205 generates tasks,thresholds, and metrics associated with the selection (at step 510). Theplan generation component 205 populates the care plan with the tasks,thresholds, and metrics. Continuing the previous example, the plangeneration component 205 may populate the care plan with tasks,thresholds, and metrics for both of the selected care plans. The careprovider may view the tasks, thresholds, and metrics via a portalinterface and customize each, e.g., by adding, editing, or removingtasks. For example, assume that the care plan protocol for diabetesincludes a task instructing the patient to record weight every morning.The care provider may customize the protocol by removing that task orediting the task to be less periodic. At step 515, the plan generationcomponent 205 receives the customizations made by the care provider.

After receiving the customizations to each of the care protocoltemplates, the plan generation component 205 determines whether anytasks or thresholds conflict with one another (at step 520). If so, thenat step 525, the plan generation component 205 resolves the conflictingtasks between the care protocol templates based on associated conflictresolution rules between the tasks. Continuing the previous example,assume that the care plan protocol for diabetes includes a task fortaking insulin seven times a day to control the glucose level of thepatient. Further assume that the care plan protocol for high bloodpressure includes a task for taking beta blockers three times a day tolower the blood pressure of the patient. Both tasks may include conflictresolution rules specifying that insulin and beta blockers should not betaken in the same care plan. In such a case, the plan generationcomponent 205 may act according to logic specified the conflictresolution rules, e.g., raising a flag to the care provider for review,adding the overriding task to the care plan and disregarding the other,etc.

At step 530, the plan generation component 205 determines whether thecustomizations provided by the care provider comply with policyinformation 112. Doing so ensures that any customizations to certaintasks are within bounds established by the policy information 112. Ifnot, then at step 535, the plan generation component 205 may flagnoncompliant tasks to the care provider for review. If so, then the plangeneration component 205 generates the care plan based on the resolvedcare protocol templates and customizations. The plan generationcomponent 205 associates the care plan with the patient and sends thecare plan to the mobile device of the patient.

FIG. 6 illustrates a sequence 600 for generating a health care plan thatmay be customized for an individual, according to one embodiment.Specifically, the sequence 600 demonstrates interactions between amobile device 601, a care platform server 602, and a physician device603 in creating a care plan.

At 605, the physician device 603 sends a request to create a care plan.In response, at step 610, the care platform server 602 sends selectablecare protocol templates to the physician device 603. At 615, thephysician device 603 sends a selection of one or more of the careprotocol templates to the care platform server 602. The care platformserver 602 populates the care plan with tasks and other metricsassociated with each of the selected care protocol templates. At 620,the care platform server 602 sends the tasks and metrics to thephysician device for customization.

At 625, the physician device 603 sends customizations for the tasks andmetrics to the care platform server 602. At 630, the care platformserver 602 resolves conflicting tasks between the selected careprotocols and customizations. At 635, the care platform server 602generates a care plan based on the selected protocols andcustomizations. Once generated, at 640, the care platform sever 602sends the generated care plan to the mobile device 601.

FIG. 7 illustrates a care platform server 700 configured to generate acare plan that may be customized for an individual, according to oneembodiment. As shown, the care platform server 700 includes, withoutlimitation, a central processing unit (CPU) 705, a network interface715, a memory 720, and storage 730, each connected to a bus 717. Thecare platform server may also include an I/O device interface 710connecting I/O devices 712 (e.g., keyboard, display and mouse devices)to the care platform server 700. Further, in context of this disclosure,the computing elements shown in the care platform server 700 maycorrespond to a physical computing system (e.g., a system in a datacenter) or may be a virtual computing instance executing within acomputing cloud.

CPU 705 retrieves and executes programming instructions stored in memory720 as well as stores and retrieves application data residing in thestorage 730. The bus 717 is used to transmit programming instructionsand application data between CPU 705, I/O devices interface 710, storage730, network interface 717, and memory 720. Note, CPU 705 is included tobe representative of a single CPU, multiple CPUs, a single CPU havingmultiple processing cores, and the like. Memory 720 is generallyincluded to be representative of a random access memory. Storage 730 maybe a disk drive storage device. Although shown as a single unit, storage730 may be a combination of fixed and/or removable storage devices, suchas fixed disc drives, removable memory cards, or optical storage,network attached storage (NAS), or a storage area-network (SAN).

Illustratively, memory 720 includes a care plan management application722. And storage 730 includes policy information 732, patientinformation 734, care protocol templates 736, and care plans 738. Thecare plan management application 722 further includes a plan generationcomponent 724 and an inventory management component 726. The plangeneration component 724 creates a care plan 738 based on a receivedselection of care protocol templates 736, received customizations of theselected templates 736, policy information 732, and patient information734.

Each care protocol template 736 provides a set of tasks, thresholds, andother metrics targeted towards treating a certain condition (e.g.,diabetes, heart issues, etc.). Although care protocol templates 736 aregeneral in nature, a care provider may modify the care protocol template736 to be specific to a given patient (e.g., by adding, editing, andremoving tasks). The plan generation component 724 may resolve conflictsbetween overlapping tasks and thresholds based on conflict resolutionrules associated with each task and threshold.

The inventory management component 726 associates sensor devices issuedby a care provider (e.g., body sensors, weight scales, etc.) withpatients. Further, the inventory management component 726 associates acare plan with a mobile device application of the patient to ensure thatthe plan generation component 205 sends the care plan to the correctmobile device.

Policy information 732 includes various guidelines (e.g., set by ahospital, standards organization, insurance companies, etc.) that eachcare protocol assigned by a care provider should adhere to. For example,the policy information 732 may specify acceptable bounds of medicationto instruct a patient to take. The plan generation component 724 mayenforce the policy information 732 when generating a care plan 738,e.g., by raising a flag for a care provider to review in the event thatthe care provider customizes a care protocol in a way that violates thepolicy information 732.

Patient information 734 includes patient medical histories and charts.Such histories and charts may provide treatment information that theplan generation component 724 may use to identify effective anddetrimental treatments (e.g., medications, exercises, etc.) applied to apatient in the past. Once identified, the plan generation component 724may modify a care plan 738 based on the identified information.

One embodiment of the present disclosure is implemented as a programproduct for use with a computer system. The program(s) of the programproduct defines functions of the embodiments (including the methodsdescribed herein) and can be contained on a variety of computer-readablestorage media. Examples of computer-readable storage media include (i)non-writable storage media (e.g., read-only memory devices within acomputer such as CD-ROM or DVD-ROM disks readable by an optical mediadrive) on which information is permanently stored; (ii) writable storagemedia (e.g., floppy disks within a diskette drive or hard-disk drive) onwhich alterable information is stored. Such computer-readable storagemedia, when carrying computer-readable instructions that direct thefunctions of the present disclosure, are embodiments of the presentdisclosure. Other examples media include communications media throughwhich information is conveyed to a computer, such as through a computeror telephone network, including wireless communications networks.

In general, the routines executed to implement the embodiments of thepresent disclosure may be part of an operating system or a specificapplication, component, program, module, object, or sequence ofinstructions. The computer program of the present disclosure iscomprised typically of a multitude of instructions that will betranslated by the native computer into a machine-readable format andhence executable instructions. Also, programs are comprised of variablesand data structures that either reside locally to the program or arefound in memory or on storage devices. In addition, various programsdescribed herein may be identified based upon the application for whichthey are implemented in a specific embodiment of the disclosure.However, it should be appreciated that any particular programnomenclature that follows is used merely for convenience, and thus thepresent disclosure should not be limited to use solely in any specificapplication identified and/or implied by such nomenclature.

As described, embodiments herein provide techniques for generating ahealth care plan that may be customized for an individual.Advantageously, the care plans that the care platform generates may betailored to a specific individual. Doing so allows a care provider toprovide a more detailed and effective approach to treating a patient'scondition than a care plan that consists of generalized tasks. Further,because the care plan may be tied to mobile and sensor devices of thepatient, the care platform may monitor the progress of the patient'sadherence to the care plan, allowing for further customization of thecare plan as necessary.

While the foregoing is directed to embodiments of the presentdisclosure, other and further embodiments of the disclosure may bedevised without departing from the basic scope thereof, and the scopethereof is determined by the claims that follow.

What is claimed is:
 1. A method comprising: generating, using aprocessor at a care platform server, a care plan for treatment of one ormore medical conditions for a patient, based on a first care protocoltemplate associated with a first treatment for the patient and a secondcare protocol template associated with a second treatment for thepatient, the generating comprising: identifying, using the processor atthe care platform server, a first patient task associated with the firstcare protocol template that conflicts with a second patient taskassociated with the second care protocol template; parsing, using theprocessor at the care platform server, the first and second careprotocol templates to identify a first conflict resolution rule, whereinthe first conflict resolution rule is pre-defined in a respectivetemplate prior to the identifying the conflict; and resolving theconflict by generating a third patient task, based on the first conflictresolution rule, and including the third patient task in the care plan;and transmitting the care plan to a client device for the patient,wherein the client device is configured to use the care plan toconfigure one or more sensor devices to collect biometric data as partof the treatment of the one or more medical conditions for the patient.2. The method of claim 1, further comprising, prior to identifying thefirst patient task that conflicts with the second patient task,determining that a first received customization relating to a first itemin the care plan complies with a first policy specifying acceptableranges of customization relating to the care plan.
 3. The method ofclaim 2, further comprising, determining that a second receivedcustomization relating to a second item in the care plan does not complywith a second policy specifying acceptable ranges of customizationrelating to the care plan, and in response disallowing the secondreceived customization such that the second received customization isnot applied to any items within the care plan.
 4. The method of claim 1,further comprising: retrieving historical patient information describingone or more previous treatment regimens for the patient; determining oneor more historical items from the one or more previous treatmentregimens that are related to a first item in the care plan; determiningone or more modifications to the first item, based on a determinedmeasure of success for one or more related historical items in the oneor more previous treatment regimens for the patient; and performing thedetermined modification on the first item within the care plan.
 5. Themethod of claim 1, wherein the care plan comprises a plurality of itemsorganized into phases of treatment for the patient, each phase includingconditions which, when satisfied, result in a transition between acurrently active phase and another one of the phases.
 6. The method ofclaim 1, wherein the care plan comprises a plurality of items, eachrelating to at least one of tasks, observation metrics, and thresholds.7. The method of claim 6, wherein tasks are actions to be performed bythe patient according to a schedule specified in the care plan, whereinobservation metrics specify biometric data to monitor from the patient,and wherein thresholds are conditions for the observation metrics that,when a care platform system detects the conditions are satisfied, causethe care platform server to perform an action in response.
 8. Anon-transitory computer-readable storage medium storing instructions,which, when executed on a processor, perform an operation, the operationcomprising: generating, using the processor at a care platform server, acare plan for treatment of one or more medical conditions for a patient,based on a first care protocol template associated with a firsttreatment for the patient and a second care protocol template associatedwith a second treatment for the patient, the generating comprising:identifying, using the processor at the care platform server, a firstpatient task associated with the first care protocol template thatconflicts with a second patient task associated with the second careprotocol template; parsing, using the processor at the care platformserver, the first and second care protocol templates to identify a firstconflict resolution rule, wherein the first conflict resolution rule ispre-defined in a respective template prior to the identifying theconflict; and resolving the conflict by generating a third patient task,based on the first conflict resolution rule, and including the thirdpatient task in the care plan; and transmitting the care plan to aclient device for the patient, wherein the client device is configuredto use the care plan to configure one or more sensor devices to collectbiometric data as part of the treatment of the one or more medicalconditions for the patient.
 9. The computer-readable storage medium ofclaim 8, wherein the operation further comprises: prior to identifyingthe first patient task that conflicts with the second patient task,determining that a received customization relating to an item in thecare plan does not comply with a policy specifying acceptable ranges ofcustomization relating to the care plan, and in response disallowing thereceived customization such that the received customization is notapplied to any items within the care plan.
 10. The computer-readablestorage medium of claim 8, wherein the operation further comprises:retrieving historical patient information describing one or moreprevious treatment regimens for the patient; determining one or morehistorical items from the one or more previous treatment regimens thatare related to a first item in the care plan; determining one or moremodifications to the first item, based on a determined measure ofsuccess for one or more related historical items in the one or moreprevious treatment regimens for the patient; and performing thedetermined modification on the first item within the care plan.
 11. Thecomputer-readable storage medium of claim 8, wherein the care plancomprises a plurality of items organized into phases of treatment forthe patient, each phase including conditions which, when satisfied,result in a transition between a currently active phase and another oneof the phases.
 12. The computer-readable storage medium of claim 8,wherein the care plan comprises a plurality of items, each relating toat least one of tasks, observation metrics, and thresholds.
 13. Thecomputer-readable storage medium of claim 12, wherein tasks are actionsto be performed by the patient according to a schedule specified in thecare plan, wherein observation metrics specify biometric data to monitorfrom the patient, and wherein thresholds are conditions for theobservation metrics that, when a care platform system detects theconditions are satisfied, cause the care platform server to perform anaction in response.
 14. A system, comprising: a processor; and a memorystoring one or more application programs configured to perform anoperation, the operation comprising: generating, using the processor ata care platform server, a care plan for treatment of one or more medicalconditions for a patient, based on a first care protocol templateassociated with a first treatment for the patient and a second careprotocol template associated with a second treatment for the patient,the generating comprising: identifying, using the processor at the careplatform server, a first patient task associated with the first careprotocol template that conflicts with a second patient task associatedwith the second care protocol template; parsing, using the processor atthe care platform server, the first and second care protocol templatesto identify a first conflict resolution rule, wherein the first conflictresolution rule is pre-defined in a respective template prior to theidentifying the conflict; and resolving the conflict by generating athird patient task, based on the first conflict resolution rule, andincluding the third patient task in the care plan; and transmitting thecare plan to a client device for the patient, wherein the client deviceis configured to use the care plan to configure one or more sensordevices to collect biometric data as part of the treatment of the one ormore medical conditions for the patient.
 15. The system of claim 14,wherein the operation further comprises, prior to identifying the firstpatient task that conflicts with the second patient task, determiningthat a received customization relating to an item in the care plan doesnot comply with a policy specifying acceptable ranges of customizationrelating to the care plan, and in response disallowing the receivedcustomization such that the received customization is not applied to anyitems within the care plan.
 16. The system of claim 14, wherein theoperation further comprises: retrieving historical patient informationdescribing one or more previous treatment regimens for the patient;determining one or more historical items from the one or more previoustreatment regimens that are related to a first item in the care plan;determining one or more modifications to the first item, based on adetermined measure of success for one or more related historical itemsin the one or more previous treatment regimens for the patient; andperforming the determined modification on the first item within the careplan.
 17. The system of claim 14, wherein the care plan comprises aplurality of items organized into phases of treatment for the patient,each phase including conditions which, when satisfied, result in atransition between a currently active phase and another one of thephases.
 18. The system of claim 14, wherein the care plan comprises aplurality of items, each relating to at least one of tasks, observationmetrics, and thresholds.
 19. The system of claim 18, wherein tasks areactions to be performed by the patient according to a schedule specifiedin the care plan, wherein observation metrics specify biometric data tomonitor from the patient, and wherein thresholds are conditions for theobservation metrics that, when a care platform system detects theconditions are satisfied, cause the care platform server to perform anaction in response.
 20. The system of claim 14, wherein the treatment ofthe one or more medical conditions for the patient is initiated by theclient device and comprises initiating an alert to a care providerrelating to the patient.